home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 12355 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.2 KB
  1. Path: keats.ugrad.cs.ubc.ca!not-for-mail
  2. From: c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku)
  3. Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu
  4. Subject: Re: C/C++ knocks the crap out of Ada
  5. Date: 19 Mar 1996 09:26:39 -0800
  6. Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
  7. Message-ID: <4imqofINNn82@keats.ugrad.cs.ubc.ca>
  8. References: <JSA.96Feb16135027@organon.com> <4i4cf2$crm@sun152.spd.dsccc.com> <adaworksDoBsy8.Brz@netcom.com> <4ikbar$g0k@tpd.dsccc.com>
  9. NNTP-Posting-Host: keats.ugrad.cs.ubc.ca
  10.  
  11. In article <4ikbar$g0k@tpd.dsccc.com>,
  12. Kevin Cline <kcline@sun132.spd.dsccc.com> wrote:
  13.  >In article <adaworksDoBsy8.Brz@netcom.com>,
  14.  >AdaWorks <adaworks@netcom.com> wrote:
  15.  > >Kevin Cline (kcline@sun152.spd.dsccc.com) wrote:
  16.  > >
  17.  > >
  18.  > >: In fact there were several serious flaws in the Ada-83 language
  19.  > >: that made development of hosted applications in Ada-83 more difficult
  20.  > >: than developing them in C or C++.  
  21.  > >
  22.  > >  I would almost agree, except my view is that Ada 83 shortcomings were 
  23.  > >  more in the category of incoveniences than "flaws."  But we are dealing
  24.  > >  with the new Ada standard.
  25.  > >
  26.  >
  27.  >I suppose every language design error could be classified as an
  28.  >inconvenience, since there is almost always some workaround available.
  29.  >But the following missing features in Ada-83 were serious problems
  30.  >when developing hosted applications and directly led to the rejection
  31.  >of Ada by the marketplace:
  32.  > 1. Inability to pass a function or procedure as an argument.
  33.  >    This went far beyond an "inconvenience" for those of us attempting
  34.  >    to use event-driven GUI libraries.  There was no portable 
  35.  >    work-around for this problem.
  36.  >
  37.  > 2. No standard interface to any OS facility more advanced
  38.  >    than line-at-a-time input/output.  Also very difficult to
  39.  >    work around, particularly if trying to produce a portable program. 
  40.  
  41. In 1983, C had no such interface either. The C language still has no interface
  42. to a terminal that is ``more advanced'' than line-at-a-time I/O. This is smart,
  43. IMHO. The comp.lang.c FAQ explains the rationale behind not including ways to
  44. do character input in the ANSI standard.
  45.  
  46. That's what POSIX.1 is for: there is a POSIX interface standard for C as well
  47. as Ada.
  48. -- 
  49.  
  50.